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Remarks: 

Entry of the above-listed amendments is respectfully requested. No new matter has been 

added. 

Claim rejections 35 USC 112, first paragraph 

The rejection of claim 1 (as well as claim 7 and claims 13-16) on the basis of examiner's 
assertion that the specification teaches scope of an access of an object rather than version of the 
object is respectfully traversed. Although, as examiner correctly cites, the specification does 
indeed teach scope of access (redaction), the specification also teaches that users can "modify" 
or "write to" the object data. Thus examiner's assertion (6/19/2007 response, page 3, third 
paragraph) that: "Thus access criteria is established to define the scope of access of an object, 
not for a version of the object as recited in claim 1 " is mistaken because it overlooks the fact that 
the specification also teaches modifying the object, therefore creating different versions. 

Here applicant is using the standard meaning of "version", as defined in the answers.com online 
dictionary, available from google.com, which is "A particular form or variation of an earlier or 
original type: downloaded the latest version of the software from the Internet. " Thus if a user 
"modifies" or "writes to" an object, this "modified" or "written to" object will be a variation of 
the earlier or original object, and thus will be a different "version" of the object. 

For example, specification page 3, paragraph 1 teaches: "Privileges could also be expanded to 
modification privileges. With modification privileges, a user can modify the data to which it has 
access by either adding or deleting information and attaching or removing other documents 
associated with the objects. This enables a type of data exchange between the host and other 
privileged users. " 

Specification page 5, paragraph 2 teaches: "Also unlike the prior art, the invention provides the 
ability to control the access by particular users according to predetermined privilege criteria, 
including reading and modifying information. " 
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Specification page 8, paragraph 1 teaches: "Furthermore, a host may allow a guest user to 
access and modify any of these objects or related attributes according to the specified privilege 
criteria set up by the host. " 

Specification figures 2, 3, and 4 illustrate that user privileges include modifying or "writing to" 
the object data. This can be found in figure 2 (208) "Read and Modify" and (216) "Modify 
application"; figure 3(306) "Modify application"; and figure 4(424) "Modify", (426) "Change", 
(428) "Add". 

Specification page 1 1 , paragraph 2 teaches: "set user privilege code 204 " and "set user privilege 
may include Read-Only code 206. This limits a guest user to read-only privileges on information 
including objects and associated documents. Without more, a user can only read an object to 
which it has access and not modify any information. " 

Specification page 29, paragraph 2 teaches: "The privileges can further allow a guest user to 
modify an object and other associated information by adding or deleting information, again, 
according to the privileges established by the host" 

The original specification claims 3, 4, 5 also teach user modification of the object. 

Thus applicant respectfully traverses the 35 USC 1 12 first paragraph rejections of claims 1, 7, 
and 13-16 on the basis that the specification does indeed teach user modification or writing to the 
object, as well as redaction. Applicant respectfully submits that the term "versions" adequately 
conveys both that the object may be redacted, and that the object may also be modified by the 
user. By contrast, the alternate term "scope of access of an object" used by examiner in page 3 
paragraph 3 of 6/19/2007 office action, only conveys the concept of "redaction", and thus does 
not adequately convey the redaction and/or modification teaching of the present disclosure. 

Claim objections: 35 USC 112 

The objection of claim 15 has been overcome. Applicant has made the requested amendment to 
claim 15 to make the requested grammatical correction at line 22. 
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Claim Rejections: 35 USC 112, second paragraph 

Claim 1 : The rejection of claim 1 under 35 USC 112 second paragraph due to lack of antecedent 
basis for the limitations: "the operation", " said application code", "the access criteria associated 
with the groups of data" has been overcome. Claim 1 has been amended to both make the 
antecedent basis for these limitations clear. 

Claim 2: The rejection of claim 2 under 35 USC 1 12 second paragraph due to lack of antecedent 
basis for the limitations: "the ability of a user", "the transferred redacted version", and " the 
requested object", has been overcome. Claim 1 has been amended to provide the required 
antecedent basis for "requested object". Note that the use of the term" requested object" has 
support in the specification, see page 20, paragraph 2, which states: "the "requested object is the 
version of the object that may be viewed or modified by said individual user. It is a redacted 
version of the object where the data that is redacted varies according to said individual user 's 
predetermined access or modification privileges ". Claim 2 has also been amended to clarify the 
wording, and correct other the antecedent basis issues. 

Claim 3: The rejections of claims 2-5 under 35 USC 1 12 second paragraph due to lack of 
antecedent basis for the limitations: "the ability", and "the requested object", has been overcome. 
Claim 1 now provides antecedent basis for "requested object", and claim 3 has been amended to 
clarify the wording and correct the other antecedent basis issues. 

Claims 4-5: The rejections of claims 4-5 under 35 USC 1 12 second paragraph due to lack of 
antecedent basis for the limitations: "the ability", and "the requested object" has been overcome. 
These claims have also been amended to clarify the wording, and correct the antecedent basis 
issues, as per claims 2 and 3. 

Claim 6: The rejection of claim 6 under 35 USC 1 12 has also been overcome. The antecedent 
basis issue with "the access" has been overcome by amending claim 6 to more clearly teach "the 
individual user's access. The antecedent basis issue with "the product chain" has been overcome 
by amending it to more precisely teach "a product supply chain", which finds support and 
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antecedent basis in the specification (page 5, paragraph 1). The antecedent basis issue with " the 
transferred redacted version" has been corrected by amending it to more precisely teach the 
"requested object", which finds antecedent basis in present claim 1 as amended. 

Claim 7: The rejection of claim 7 under 35 USC 1 12 has been overcome. As per the earlier 
claims, claim 7 has been amended to improve clarity and to provide antecedent basis for the 
limitations. 

Claim 8: The rejection of claim 8 under 35 USC 1 12 has been overcome. Claim 8 has been 
amended to now clearly teach on single type of object. 

Claim 1 1 : The rejection of claim 1 1 under 35 USC 1 12 has been overcome. Claim 1 1 has been 
amended to more clearly teach which type of object is being referenced. 

Claim 12: The rejection of claim 12 under 35 USC 1 12 because of lack of antecedent basis for 
the limitation "the requestor" is respectfully traversed because the limitation "the requestor" is 
not actually present in the present version of the claim. However claim 12 has been amended to 
improve the antecedent basis for "electronic object". Additionally, claims 8 and 11, which did 
contain the term "the requestor" and which had suboptimal language from an antecedent basis 
standpoint, have been amended to correct this issue. 

Claim Rejections: 35 USC 112 (lack of specification support) 

Claim 1: The rejection of claim 1 on the basis of examiner's assertion that "the access criteria 
associated with the groups of data contained within a version of an object" was not described in 
the specification is respectfully traversed in part and overcome in part. To traverse, applicant 
respectfully submits that the cited phrase is composed of the limitations "access criteria", 
"groups of data" and "version of an object", and proving or disproving examiner's assertion thus 
becomes one of determining if these three limitations were taught in the specification. 
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Examiner had previously expressed a belief that concepts supporting "version of an object" were 
not present in the specification. To overcome this incorrect perception, applicant earlier 
provided appropriate citations earlier in this response (specification page 3 paragraph 1 ; page 5 
paragraph 2; page 8 paragraph 1; figures 2, 3, 4; page 1 1 paragraph 2; page 29 paragraph 2; and 
original claims 3, 4, 5) demonstrating that the specification supports both redacted objects, and 
user "writing to" or "modification of objects, thereby providing support for the "versions of an 
object" limitation. 

Specification support for the "groups of data" limitation, showing specification support for the 
data elements in the object (which comprises distinguishable groups of data), was provided in the 
previous 3/21/2007 response to the previous 9/20/2006 office action. See the 3/21/2007 response 
pages 16-18. 

Specification support for the "access criteria" limitation can be found in specification page 2 
paragraph 2 ("trade secrets" "confidentially among business partners", "established business 
relationships"); page 3 paragraph 1 ("confidential information"); page 3 paragraph 2 
("predetermined privileges set by the owner of the information", "host status", "guest status"); 
page 5 paragraph 1 ("original equipment manufacturer", "contract equipment manufacturer"); 
and page 14 paragraph 1 ("user ID"); as well as elsewhere in the specification. 

Further, applicant respectfully submits that specification figures 2, 3, 4, 5, 6, 7A, 8 and illustrate 
how these different limitations relate to form the "the access criteria associated with the groups 
of data contained within a version of an object" limitation. For example, figure 8 shows how a 
guest (802) with guest "access criteria" interacts with the guest ID "access criteria", which then 
verifies that the guest satisfies the access criteria (814). If this criteria is acceptable, the system 
retrieves data (824) from the "groups of data" contained within that version of the object (834) 
and sends the data to the guest. 

Thus applicant respectfully traverses this 35 USC 1 12 claim 1 rejection on the basis that the cited 
limitations are, in fact disclosed in the specification. Applicant respectfully overcomes this 
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rejection as well by amending claim 1 to better clarify the antecedent basis of the various 
limitations. 

Claim 7: The rejection of claim 7 under 35 USC 1 12 on the basis of examiner's assertion that 
"the access criteria associated with the groups of data contained within the version of the 
redacted object transferred" was not described in the specification is overcome in part and 
traversed in part. To overcome, applicant has amended claim 7 to clarify the claim wording and 
to define a "requested object" term to define this concept more precisely. A "requested object" 
is "a redacted version of an object according to access criteria established for a user" 

Applicant respectfully submits that teaching transference of such redacted objects is supported 
by the specification in multiple places including page 3, paragraph 3; page 1 1 paragraph 2; and 
original claims 12, 13, and 14. If necessary, applicant can amend the specification by bringing 
the teaching from original claims 12, 13, and 14 into the specification, but since this teaching is 
already present in specification page 3 paragraph 3, and page 1 1 paragraph 2; applicant believes 
that such amendment is not needed unless examiner specifically requests it. 

As per the traversal of claim 1, above, applicant respectfully submits that the other elements in 
the rejected phrase: "access criteria", "groups of data" and "version" are in fact supported by the 
specification, as were previously demonstrated in the 35 USC 1 12 claim 1 traversal discussion. 

Claims 13 and 14: The rejection of claims 13 and 14 under 35 USC 1 12, on the basis of 
examiner's assertion that "establishing privilege access criteria that define the scope of access of 
a version of the object for the user" was not described in the specification, is respectfully 
traversed. 

As per the earlier traversal arguments for claims 1 and 7, applicant respectfully submits that 
"privilege", is an alternate term for levels of access. This concept was disclosed in specification 
page 3 paragraphs 2-4; page 4 paragraph 1, and elsewhere in the specification. 
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The specification support for other limitations such as "access criteria" and "version" was 
extensively cited and discussed earlier in this response. To keep this response to a manageable 
length, applicant respectfully refers examiner to these earlier citations, and incorporates them 
into the claim 13 and 14 response as well. 

Applicant additionally notes that page 4 paragraph 1 of the specification teaches "Access to 
objects and associated documents can also be limited to read-only privileges... Privileges could 
also be expanded to modification privileges. With modification privileges, a user can modify the 
data to which it has access by either adding or deleting information and attaching or removing 
other documents associated with the objects . This enables a type of data exchange between the 
host and other privileged users. " [Emphasis added] Since a modified object is a different 
version of the object, and since "privilege" relates to "access criteria", the specification is in this 
single excerpt teaching: "establishing privilege access criteria that define the scope of access of 
a version of the object for the user 11 . Applicant respectfully submits that alternate phrasing is 
allowed under MPEP 2163.07. 

Thus applicant respectfully traverses the rejection of claims 13 and 14 under 35 USC 1 12, on the 
basis that in fact the specification does teach these specific limitations. This traversal argument 
also applies for the 35 USC 112 rejections of the same limitations in claims 15 and 16. 

Claim 15: The rejection of claim 15 under 35 USC 112 on the basis of examiner's assertion that 
"establishing privilege access criteria that define the scope of access of a version of the object 
for the user' 1 was not described in the specification is respectfully traversed, using the same 
arguments previously given for claims 13 and 14. The rejection on the basis of examiner's 
assertion that "setting up a redacted version of an object and associated documents according to 
user access privileges for transmission to the individual user' 7 was not described in the 
specification is also respectfully traversed. 

To begin, applicant respectfully submits that examiner has selected a relatively long passage 
containing many limitations that clearly are in the specification, but has not identified with 
specificity exactly which limitations examiner believes are not present in the specification. 
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Applicant respectfully traverses on a first basis that, under MPEP 2163.07. "Mere rephrasing of 
a passage does not constitute new matter. Accordingly, a rewording of a passage where the same 
meaning remains intact is permissible. In re Anderson, 471 F.2d 1237, 1 76 USPQ 331 (CCPA 
1973). Accordingly, applicant will submit several citations from the original filing that provide 
support for the present claim language: 

Specification page 3, paragraph 3 teaches: "In operation, after given an access identification, a 
user can access the database system and request access to an object . The system then retrieves 
information pertaining to the individual user 's privilege criteria and determines which 
information contained in the database may be accessed by the requestor. The system then filters 
the information including objects, their attributes and associated documents according to the 
privilege information and gives the user limited access to the information. The requested and 
approved information can then be sent to the requestor of the information. This could also be 
displayed to the user as a document file having a redacted document blocking out the 
information that the user is not privileged to see" [Emphasis added]. 

Original claim 12, submitted with the original specification, also states the same concept in an 
alternative form. Original claim 12 reads ''wherein transmitting a redacted object includes 
sending an electronic object to the requestor that contains the groups of information to which the 
requestor has access to and that excludes groups of information to which the requestor does not 
have access. " Applicants are allowed to amend the specification to incorporate material 
disclosed in claims originally submitted with the specification. Although applicant believes that 
the specification presently contains adequate support for these limitations, applicant is willing to 
amend the specification to include the teaching of original claim 12 if examiner believes that this 
is necessary. 

Applicant also respectfully submits that the present specification teaches this concept in other 
places, such as page 1 1 paragraph 2; original claims 13, and 14, and figure 8. For example, 
figure 8 shows "setting up a redacted version of an object (824) and associated documents 
according to user access privileges (804), (814) for transmission to an individual user (834)." 
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Thus applicant respectfully traverses the rejection of claim 15 under 35 USC 1 12 on the basis 
that the specification does support these claim limitations. 

Claim 16: The rejection of claim 16 under 35 USC 1 12 on the basis of examiner's assertion that 
"establishing privilege access criteria that define the scope of access of a version of the object 
for the user" was not described in the specification is respectfully traversed as discussed above 
for claims 13 and 14. The rejection on the basis of examiner's assertion that "setting up a 
redacted version of an object and associated documents according to user access privileges " 
was not described in the specification is also respectfully traversed as discussed above for claim 
15. The rejection on the basis of examiner's assertion that "receiving an object request by a user 
via a network for access to a version of an object" is not described in the specification is 
respectfully traversed as discussed below. 

As before, applicant respectfully traverses on a first basis that, under MPEP 2163.07. "Mere 
rephrasing of a passage does not constitute new matter Accordingly, a rewording of a 
passage where the same meaning remains intact is permissible. In re Anderson, 471 F.2d 1237, 
176USPQ 331 (CCPA" 

Applicant also respectfully submits that the specification uses the alternate term "guest" to 
describe "users". See specification page 3 paragraph 2, which states: " Individual users, or 
guests, can be given access to the objects... " 

To traverse by showing support in the specification, applicant respectfully submits that 
specification figures 1, 2, 3, 4, 7A 3 and 7B graphically show this limitation. In particular see 
specification figure 1, which shows an overview of the networked system (126), used by a guest 
(user) using a guest (user) computer (154); and figure 8 which shows a flow chart. This flow 
chart shows "receiving an object request (806) by a user (808), via a network (126) for access to 
a version of an object (824) ". 

In addition to showing this concept in the figures, the specification also discloses this concept in 
the text as well. For example, specification page 5 paragraph 2 states that "the invention 
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provides a information management system 100 for use over a network 126 so that information 
can be transferred among multiple users. " Specification page 29 paragraph 2 teaches that "The 
invention is intended as an information retention system for use by multiple users of the network 
system. The system allows multiple access to a particular document established by a host user, 
but allows a host user to control the access of the document by guest users according to specific 
privileges. These privileges can include the ability to read information contained in an object 
and to possibly redact sections so that a guest user cannot read all of the data contained therein. 
The privileges can further allow a guest user to modify an object and other associated 
information by adding or deleting information, again, according to the privileges established by 
the host. " [Emphasis added]. As previously discussed, since users can modify an object, they 
create object versions . Thus the "version" limitation finds support in this passage as well. 

Thus applicant respectfully traverses the rejection of claim 16 under 35 USC 1 12 on the basis 
that support for the rejected material is, in fact, found in the specification. 

Claim Rejections - 35 USC 112 (indefinite) 

Claim 1 : The rejection of claim 1 under 35 USC 1 12 on the basis that ' 'the operation ", " said 
application code ", "the access criteria associated with the groups of data contained within a 
version of an object" lack antecedent basis has been overcome. Claim 1 has been amended to 
correct these antecedent basis problems. 

Claim 2: The rejection of claim 2 under 35 USC 1 12 on the basis that there is insufficient 
antecedent basis for the limitations "the ability of a user, the transferred redacted version and 
the requested object " has been overcome. Claim 2 has been amended to correct these antecedent 
basis problems. 

Claims 3-5: The rejections of claims 3-5 under 35 USC 1 12 on the basis that there is insufficient 
antecedent basis for the limitations "the ability and the requested element" have been overcome. 
Claims 3-5 have been amended to correct these antecedent basis problems. 
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Claim 6: The rejection of claim 6 under 35 USC 1 12 on the basis that there is insufficient 
antecedent basis for the limitations "the access, the product chain, the transferred redacted 
version " has been overcome. Claim 6 has been amended to correct these antecedent basis 
problems. 

Claim 7: The rejection of claim 7 under 35 USC 1 12 on the basis that the limitations, "the 
database, the transferred version, the access criteria associated with the groups of data contained 
within the version of the redacted object," and the "redacted object" lack of clarity have been 
overcome. Claim 7 has been amended to correct these antecedent basis and lack of clarity 
problems. 

Claim 8: The rejection of claim 8 under 35 USC 1 12 on the basis that the limitations, "the 
redacted version of the object" and references to a plurality of "redacted version of an object" are 
unclear has been overcome. Claim 8 has been amended to refer to the clearer term "requested 
object". Claim 7 has also been amended in this way. 

Claim 1 1 : The rejection of claim 1 1 under 35 USC 1 12 on the basis that "the version of the 
object" references to other items in the claims has been overcome. Claim 7, 8, and 1 1 have been 
amended to refer to the clearer term "requested object". 

Claim 12: The rejection of claim 12 on the basis that there was insufficient antecedent basis for 
the limitation "the requestor" is respectfully traversed. There is no term "the requestor" in the 
present version of the claim. However a potential antecedent basis issue with "electronic object" 
was corrected by amending the claim to now teach "requested object". 

Claim Rejections, 35 USC 103(a) 

The rejection of claims 1-9 and 12-16 under 35 USC 103(a) over Schneck (USP 6,314,409) in 
view of Mukherjee (USP 5,317,729) is respectfully traversed. In addition to the traversal 
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arguments given below, applicant also reiterates the 35 USC 103 arguments traversing Schneck 
and Mukherjee that were provided in the previous 3/21/2007 response. 

35 USC 103(a) rejection of claims 1-9 and 12-16 in view of Schneck and Mukherjee: 

The rejection of claim 1, as well as the other claims 2-9 and 12-16 under 35 USC 103(a) as being 
obvious over Schneck in view of Mukherjee is respectfully traversed. Applicant traverses on the 
general grounds that in various places, the rejection did not accurately cite the limitations that 
were taught by the present specification, Schneck, or Mukherjee. When the various sources are 
examined in more detail, it can be seen that the actual limitations differ from the limitations cited 
in the rejection. The actual limitations do not support the various 35 USC 103(a) rejection 
arguments. Here, applicant will respectfully provide evidence to support this traversal. 

Claim 1: Applicant respectfully submits that in the rejection, examiner has prematurely 
truncated his quotation of claim 1. Specifically, in examiner's arguments that Schneck teaches 
"a system for providing the transfer of and the controlled access to a version of an object and 
other information of a file by a plurality of users " examiner quoted a fragment of present claim 1 
that omits important limitations. In fact, when this portion of claim 1 is quoted in context, it 
becomes clear this portion of claim 1 contains important limitations that were not taught by 
Schneck. 

A fuller and more complete quotation of this portion of claim 1 is: 

"A business-entity data-exchange system for providing the transfer of and the controlled access 
to a version of an object and other associated information of a file by a plurality of users from 
different business entities, said business entities being business partners or potential business 
partners producing products and component parts throughout a product supply chain " 
[emphasis added] 

Although examiner asserts that Schneck teaches the limitation that "Schneck teaches a method 
and a business entity data exchange system " There is no evidence that Schneck contemplated 
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business entities and product supply chains. As discussed in more detail in the 3/21/2007 
response, Scheck was teaching a media (movie, computer program, sound recording) oriented 
data access system where the data objects (files) themselves had intrinsic value, and access was 
primarily controlled by simple prior-art criteria such as payment or age of viewer (for G or X 
rated movies). These data access algorithms are not appreciably more sophisticated than the data 
access algorithms commonly used to check out videos from a video rental store. Schneck does 
not teach " different business entities, said business entities being business partners or potential 
business partners producing products and component parts throughout a product supply chain " 
and examiner has not provided citations from Schneck that cover these areas. 

In fact, examiner admits this deficiency by stating on page 3 paragraph 1 of the 6/19/07 office 
action that: "The missing of Schneck is the claimed limitation in the preamble, business partners 
or potential business partners producing products and component parts throughout a product 
supply chain and the predetermined access vary according to the status of the business 
relationship. " 

Although examiner tries to repair this deficiency by asserting that "Mukherjee further discloses 
business partners or potential business partners producing products and component parts 
throughout a product supply chain ", applicant respectfully submits that examiner is misquoting 
or misinterpreting Mukherjee, and has misquoted or misinterpreted the normal meaning of the 
terms "business partners" and "product supply chain". 

Here, the normal meaning of the term "supply chain" is highly relevant. Typing "supply chain" 
into google.com shows that the standard definition of "supply chain" according to the 
answers.com dictionary, is "The network created amongst different companies producing, 
handling and/or distributing a specific product " [emphasis added] 

Applicant respectfully submits that Mukherjee in fact was teaching art intended to be used by 
employees within a single company to control work processes within a single company . 
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It is quite common for a single company, particularly a large company, to have different 
departments (design engineering, manufacturing engineering, etc.). However if the different 
departments are in the same company, they ultimately will report to the same person in upper 
management. This person may be the CEO, or a lower level manager such as a vice president of 
engineering or a vice president of operations (in the case of the design engineering and 
manufacturing engineering departments). If the different departments are in the same company, 
the different departments also are often funded by sales of the same products. As a result, 
employees and processes within a single company generally have a fairly high level of trust. 

By contrast, the trust level between different companies is much lower. If the sales department 
form company "A" can obtain advance knowledge of the price or features of company "B's" 
products, company "A" can use this information to outbid company "B" 5 potentially driving 
company "B" out of business and causing great distress to company "B's" employees, 
management, and owners. 

At the same time, the complex nature of modern products is such that different companies that 
compete against each other must also cooperate and make components for each other, and must 
exchange enough information to do so. The resulting scenario is not unlike a poker game from 
the Wild West. Competitor companies uneasily cooperate with each other, exchanging some 
information, while holding key information (such as the exact hand of poker cards that they are 
playing) secret. The present art is designed for just such a "low trust but we must exchange 
some information to survive" business environment that exists when different companies supply 
components and services to each other. 

As a result, users operating within a company do not need to have as an elaborate system of 
access criteria and redaction as is discussed in the present disclosure. In the higher trust 
environment that exists within a company, much simpler authorization schemes are adequate. 
Low trust computer systems are a relatively new development. Prior art systems, such as 
Mukherjee, avoided low trust situations, and simply assumed that everyone that had access was a 
relatively high trust user that worked for the same company. 
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The assumption that the work is proceeding within a single company can be seen throughout 
Mukherjee. The reasons for this are easy to understand. Mukherjee was an employee of one of 
the world's largest corporations, International Business Machines (IBM). In 1990, the date 
Mukherjee submitted the application, IBM was a global organization comprised of over 370,000 
employees. IBM produced many of its own components using various internal departments, 
including design engineering and manufacturing engineering departments. In effect, IBM was its 
own "high trust" world. 

Mukherjee's lack of "low trust" art relevant to work between different businesses of companies 
is easy to verify. Applicant respectfully submits that a computer scan of Mukherjee shows that 
the terms "company," "organization," "partners," "supply chain," and "business" are completely 
absent from the disclosure. 

Although applicant respectfully submits that the limitation "from different companies" is part of 
the standard definition of "supply chain"; and the "supply chain" limitation is already present in 
claim 1 and other claims. However to make this limitation clearer, applicant has respectfully 
overcome the rejection by amending claim 1, and all other independent claims, to further recite 
that the business partners or potential business partners or business entities are from different 
companies . 

Support for the "different company" limitation can be found in specification page 2 paragraph 1 . 
Additional support is provided by the standard definition of "supply chain" "The network created 
amongst different companies producing, handling and/or distributing a specific product ". The 
"supply chain" teaching can be found in the present specification at page 2 paragraph 1 ; and page 
5 paragraph 1 . 

Claim 2: The 35 USC 103(a) rejection of claim 2 is respectfully traversed. Claim 2 is a 
dependent claim to claim 1, which now contains the "different companies" teaching not 
anticipated by Schneck and Mukherjee. 

Claim 3: The 35 USC 103(a) rejection of claim 3 is respectfully traversed in part and overcome 
in part. Claim 3 is a dependent claim to claim 1, which now contains the "different companies" 
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teaching not anticipated by Schneck and Mukherjee. Applicant also traverses on the additional 
grounds that the Schneck (col 26, lines 30-31) only teaches printing out modified versions of the 
object such as a customized book. Schneck does not teach storing the modified contents back in 
the memory of the application server. Applicant has overcome this rejection by amending claim 
3 to teach storing the modified contents in memory. 

Support for this amendment may be found in the specification figure 2, and page 3 paragraph 2 
which shows guest privileges (210) which include modify application code (216), which, allows 
guests (users) to modify memory (1 14), (112), (230) on host computer (104). Further support is 
given on page 29 paragraph 2. 

Claim 4: The 35 USC 103(a) rejection of claim 4 is respectfully traversed in part and overcome 
in part. Claim 4 is a dependent claim to claim 1, which now contains the "different companies" 
teaching not anticipated by Schneck and Mukherjee. As per claim 3, applicant also traverses on 
the additional grounds that Schneck (col 26, lines 30-31) only teaches printing out modified 
versions of the object such as a customized book. Schneck does not teach deleting the contents 
from the memory of the application server. Applicant has overcome this rejection by amending 
claim 4 to teach storing the modified object in memory. 

As before, support for this amendment may be found in the specification figure 2, and page 3 
paragraph 2 which shows guest privileges (210) which include modify application code (216), 
which, allows guests (users) to modify memory (1 14), (1 12), (230) on host computer (104). 
Further support is given on page 29 paragraph 2. 

Claim 5: The 35 USC 103(a) rejection of claim 5 is respectfully traversed in part and overcome 
in part. Claim 5 is a dependent claim to claim 1, which now contains the "different companies" 
teaching not anticipated by Schneck and Mukherjee. As per claim 3 and 4, applicant also 
traverses on the additional grounds that the Schneck (col 26, lines 30-31) only teaches printing 
out modified versions of the object, such as a customized book. Schneck does not teach adding 
data to the memory of the application server. 

As per claim 3 and 4, applicant has overcome this rejection by amending claim 4 to teach this 
limitation. Support for this amendment may be found in the specification figure 2, and page 3 
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paragraph 2 which shows guest privileges (210) which include modify application code (216), 
which, allows guests (users) to modify memory (1 14), (1 12), (230) on host computer (104). 
Further support is given on page 29 paragraph 2. 

Claim 6: The 35 USC 103(a) rejection of claim 6 is respectfully traversed in part and overcome 
in part. Claim 6 is a dependent claim to claim 1, which now contains the "different companies" 
limitations not anticipated by Schneck and Mukherjee. 

Claim 8: The 35 USC 103(a) rejection of claim 8 is respectfully traversed in part and overcome 
in part. Claim 8 is a dependent claim to claim 7, which now contains the "different companies" 
limitations not anticipated by Schneck and Mukherjee. 

Claim 9: The 35 USC 103(a) rejection of claim 9 is respectfully traversed in part and overcome 
in part. Claim 9 is a dependent claim to claim 7, which now contains the "different companies" 
limitations not anticipated by Schneck and Mukherjee. 

Claim 12: The 35 USC 103(a) rejection of claim 12 is respectfully traversed in part and 
overcome in part. Claim 12 is a dependent claim to claim 7, which now contains the "different 
companies" limitations not anticipated by Schneck and Mukherjee. 

Claims 13 and 14: As previously discussed for claim 1, applicant respectfully traverses and 
overcomes these rejections by amending claims 13 and 14 to contain the "different companies" 
limitations not anticipated by Schneck and Mukherjee. 

As per claim 1, applicant respectfully traverses a number of the other specific claim 13 and 14 
rejections on the general grounds that in various places, the rejection did not accurately cite the 
limitations that were taught by the present specification, Schneck, or Mukherjee. When the 
various sources are examined in more detail, it can be seen that the actual limitations differ from 
the limitations cited in the rejection. The actual limitations do not support the various 35 USC 
103(a) rejection arguments. Here, applicant will respectfully provide evidence to support this 
traversal. 
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Applicant thus traverses on the additional grounds that, as per claim 1, the Schneck abstract, 
cited by examiner, does not contain the alleged reference to "business entities" or marking or 
altering objects. 

Applicant further traverses on the additional grounds that as per claim 1, Schneck Figure 1 does 
not disclose that "the user privilege access criteria varies according to the business entity that 
said individual user is affiliated with". Schneck, who was essentially teaching a media 
dispensing kiosk, simply teaches payment, and teaches no such dependence on any business 
entities that the user may be affiliated with. Applicant respectfully submits that examiner's 
insertion of the additional limitation "according to the payment" in his quotation of applicant's 
claim has the net effect of mutating applicant's claim and limitations into an incorrect form. 

Applicant further traverses on the additional grounds that as per claim 1, Schneck col 23, line 65- 
Col 24, line 1 is not teaching "business entity that said individual user is affiliated". What these 
lines actually say is: "A permission list consists of rules governing the qualities and quantities of 
access made available by the owner to a particular user or group or class of users, and defines 
those ways in which the user may (and may not) interact with the owner's data/information" 
There is no actual discussion of user affiliation, or business, or business entities. 

Although applicant agrees with examiner's statement that "the missing of Schneck is the status of 
the business partnership that makes the user privilege access criteria vary", applicant 
respectfully traverses examiner's assertion that "Mukherjee further discloses the predetermined 
access vary according to the status of the business partnership". As previously discussed for 
claim 1, Mukherjee's specification completely lacks the terms "company" "organization" 
"partners" "supply chain" or "business"; and also lacks the terms "partner" or partnership". As 
previously discussed for claim 1, Mukherjee's use of the term status (e.g. design engineering, 
manufacturing engineering) is only in the higher-trust context that exists within a single 
company, not between companies. 

Applicant respectfully submits that, as per claim 1, Mukherjee figure 4, cited by examiner, in 
fact contains no business partnership teaching whatsoever as far as the present context of 
relationships between different companies is concerned. 
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Since neither Schneck nor Mukherjee contains any relevant teaching as far as regulating 
information exchange between companies, applicant respectfully traverses the 35 USC 103(a) 
rejection of claims 13 and 14 that it would have been obvious to apply this technique by 
combining references. 

Claims 15 and 16: As previously discussed for claim 1, applicant respectfully traverses and 
overcomes these rejections by amending claims 15 and 16 to contain the "different companies" 
limitations not anticipated by Schneck and Mukherjee. 

As per claim 1 and claims 13 and 14, applicant respectfully traverses a number of the other 
specific claim 15 and 16 rejections on the general grounds that in various places, the rejection 
did not accurately cite the limitations that were taught by the present specification, Schneck, or 
Mukherjee. When the various sources are examined in more detail, it can be seen that the actual 
limitations differ from the limitations cited in the rejection. The actual limitations do not support 
the various 35 USC 103(a) rejection arguments. Here, applicant will respectfully provide 
evidence to support this traversal. 

Applicant further traverses on the additional grounds that, as per claim 1,13, and 14, Schneck 
Figure 1 does not disclose that "the user privilege access criteria varies according to the 
business entity that said individual user is affiliated with". Schneck, who was essentially 
teaching a media dispensing kiosk, simply teaches payment, and teaches no such dependence on 
any business entities that the user may be affiliated with. Applicant respectfully submits that 
examiner's insertion of the additional limitation "according to the payment" in his quotation of 
applicant's claim has the net effect of mutating applicant's claim and limitations into an incorrect 
form. 

Applicant further traverses on the additional grounds that as per claim 1,13, and 14, Schneck col 
23, line 65-Col 24, line 1 is not teaching "business entity that said individual user is affiliated". 
What these lines actually say is: "A permission list consists of rules governing the qualities and 
quantities of access made available by the owner to a particular user or group or class of users, 
and defines those ways in which the user may (and may not) interact with the owner's 
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data/information'' There is no actual discussion of user affiliation, or business, or business 
entities. 

Although applicant agrees with examiner's statement that "the missing of Schneck is the status of 
the business partnership that makes the user privilege access criteria vary", applicant 
respectfully traverses examiner's assertion that "Mukherjee further discloses the predetermined 
access vary according to the status of the business partnership". As previously discussed for 
claim 1,13 and 14, Mukherjee's specification completely lacks the terms "company" 
"organization" "partners" "supply chain" or "business"; and also lacks the term "partnership". 
As previously discussed for claim 1,13 and 14, Mukherjee's use of the term status (e.g. design 
engineering, manufacturing engineering) is only in the higher-trust context that exists within a 
single company, not between companies. 

Since neither Schneck nor Mukherjee contains any relevant teaching as far as regulating 
information exchange between companies, applicant respectfully traverses any conclusion that it 
would have been obvious to apply this technique by combining references. 

Claim 11: The rejection of claim 1 1 in view of the combination of Schneck, Mukherjee, and 
Hayes is respectfully traversed. Claim 1 1 is a dependent claim to claim 7, and thus inherits the 
user "business relationship" and "different company" imitations not taught by any combination 
of Schneck and Mukherjee. 

Hayes does nothing to repair the deficiency Schneck and Mukherjee in teaching "low trust" 
systems that operate between different companies. As per Schneck and Mukherjee, a computer 
scan of Hayes shows Hayes also lacks the terms "company", "organization", "partners", "supply 
chain", "business", and also has no teaching regarding trust relationships between different 
companies. 

Additional grounds for traversal of obviousness: commercial success 

As an alternative ground of traversal for the 35 USC 103 obviousness rejections, applicant 
respectfully submits evidence of commercial success. 
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According to MPEP 1504.03 Nonobviousness: ///. REBUTTAL OF THE PRIMA FACIE CASE 

Once a prima facie case of obviousness has been established, the burden shifts to the applicant 
to rebut it, if possible, with objective evidence of nonobviousness. Examples of secondary 
considerations are commercial success, expert testimony and copying of the design by others. 
Any objective evidence of nonobviousness or rebuttal evidence submitted by applicant, including 
affidavits or declarations under 37 CFR 1.132, must be considered by examiners in determining 
patentability under 35 U.S.C. 103(a). 

Although applicant has argued and presented extensive evidence that no such prima facie 
obviousness case exists, and although applicant does not stipulate obviousness, applicant 
believes that there have been some recent commercial developments are relevant to any 
obviousness rejections made in this application. Here, applicant presents a brief overview of 
these commercial developments. 

Objective evidence that the invention has achieved commercial success: 

The present invention plays a key role as a major part of the Agile Software Corporation 
"Product Lifecycle Management" (PLM) System. This is the main product sold by Agile. Until 
its recent purchase by Oracle Corporation in May 2007 for $495 million, Agile Software 
Corporation was a publically traded corporation. As a result, the company has filed audited and 
legally binding reports and documents, as required by the Security and Exchange Commission 
and the Sarbanes Oxley Act. Here, certain information provided in the Agile 2005 annual report 
will be cited. 

According to Agile's 2005 annual report, the company's main line of business was selling 
product lifecycle management software along the lines of the present invention. As stated in this 
2005 annual report: 
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"We develop and sell an integrated suite of product lifecycle management ("PLM") software 
products and offer related business consulting and implementation services. Our solutions 
enable our customers to accelerate their time-to-market and revenue, reduce costs, improve 
product quality, ensure regulatory compliance and drive innovation throughout the product 
lifecycle. Albertsons, Alcatel, Boeing Service Company, Cisco Systems, Dell Computer Products, 
Eastman Kodak, Flextronics International, GlaxoSmithKline, Harris Corporation, Hitachi 
Corporation, LeapFrog Enterprises, Lockheed Martin Missile and Fire Control, Magna Steyr, 
Philip Morris International, Siemens A&D, QUALCOMM Corporation and ZF are among the 
over 10,000 customers that have licensed Agile solutions. " (Agile 2005 annual report, page 1, 
paragraph 1) 

Direct Materials Sourcing. As manufacturers outsource more and more of their production 
requirements, including in many cases engineering activities, to third-party suppliers, they no 
longer have direct control over the internal procedures used to design and build their products. 
To ensure high quality, cost effective and timely availability of products, product information 
and changes must be communicated effectively across a very complex, global supply chain . 
(Page 1, last paragraph). 

Described below are the principal software products we offer. Many of these products are tightly 
integrated and may be purchased and used as a combined solution set. 

Agile Product Collaboration /Product Data Management. Agile Product Collaboration 
manages product information including bills of material, documentation, engineering and 
manufacturing changes, configurations, and mechanical, electrical and software design and 
analysis databases, providing visibility to this information throughout the extended enterprise 
and streamlining the product development and delivery process. (Page 2, last two paragraphs). 

Agile Product Cost Management. Agile Product Cost Management provides product cost 
intelligence between internal design and sourcing functions on the one hand and external 
supplier and partners on the other hand, and is used to streamline the direct materials sourcing 
process. Using Agile Product Cost Management, customers can plan and manage critical cost, 
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commercial terms and other key product information early and throughout the product lifecycle. 
This enables users to achieve product total cost goals by promoting the use of preferred 
suppliers, aggregating demand across multiple organizations for greater buying power, and 
sharing product information across the supply chain, (page 3 second paragraph) 

Agile Content Framework The Agile Content Framework links the product record in real-time to 
component information dispersed throughout the supply chain enabling evaluation and 
consolidation of manufacturer, enterprise and supplier information obtained from dispersed 
sources for optimal decision making throughout the product lifecycle. Component Bill of 
Material and Approved Manufacturer / Vendor List data can be analyzed, cleansed, and mapped 
to consolidate product information coming from multiple sources like component catalogs into a 
usable asset for the engineering and sourcing organizations , (page 4, paragraph 7) [emphasis 
added] 

Consolidated Statement of Operations Data (2005) 

Revenues: 

License $ 46,406,000 

Service $70,581,000 

Total revenues $116,987,000 

(page 13, top) 

Applicant respectfully submits that in view of the invention's key part in Agile's PLM software 
system, the substantial revenues from this system, and the company's recent acquisition for $495 
million, any argument purporting to establish prima facie obviousness can be rebutted by this 
objective evidence of commercial success. 

Applicant further submits that Oracle, the acquiring corporation, is highly sophisticated in 
business software, and its positive assessment of the Agile PLM, which uses the present art, is 
relevant. Oracle is widely known for expertise in enterprise software and databases, and has 
enterprise database and data management software sales of approximately $14.2 billion dollars 
per year. According to the Oracle May 15 press release: 
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REDWOOD SHORES, Calif. 15-MAY-2007 02:15 PM Oracle announced today that it has 
agreed to acquire Agile Software Corporation (Nasdaq: AGIL), a leading provider of product 
lifecycle management (PLM) software solutions, through a cash merger for $8.10 per share, or 
approximately $495 million. 

Agile's PLM solutions help engineers, manufacturing and supply chain professionals and 
business executives drive the product innovation and introduction process, share product 
specifications and configurations and collaborate effectively across the supply chain in a variety 
of industries, including high-tech, life sciences, industrial manufacturing and consumer 
packaged goods. Agile's solutions help customers make better product portfolio decisions, 
accelerate new product introduction, improve manufacturing quality and manage regulatory 
compliance. Customers of Agile include Acer, Flextronics International, GE Medical Systems, 
Harris, Heinz, Johnson & Johnson, Lockheed Martin, McDonald's, Micron, QUALCOMM, Shell 
and ZF. 

Applicant thus respectfully traverses the 35 USC 103(a) rejection of all claims on the basis of 
commercial success. 

New claims: 

New claim 17-19 are restated versions of claims 1, 7 and 13 with a smaller Markush group of 
database groups of business relationship data. This smaller group contains data elements 
pertaining to relationships between different companies in the supply chain, and thus focuses on 
data types not taught by any combination of Schneck or Mukherjee. 



37 



Attorney Docket No. AGIL-00500 



In view of the above amendments and accompanying remarks, applicant believes that the 
application is now in condition for allowance. Notice to that effect is respectfully requested. 

The Commissioner is authorized to charge any additional fees due or credit any overpayment to 
Deposit Account No. 50-2421 . 

If there are any questions regarding this correspondence, please contact the undersigned at (408) 



288-7588. 



Respectfully submitted, 



Dated: August 29, 2007 




DaVreTR. Stevens 
Reg. No. 38,626 



Stevens Law Group 



P.O. Box 1667 



San Jose, CA 95109 
Tel (408) 288-7588 
Fax (408) 288-7542 
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